Computer software utilization worldwide has increased considerably in recent years. Computer software is employed by individual users for such tasks as word processing and electronic mail, among other things. Companies utilize software for all aspects of business management including data storage, communication, and electronic commerce. Essentially, computer software has become ubiquitous. Accordingly, software developers and vendors need to design software for a diverse customer base, which is essentially the world. Thus, designers can no longer make broad assumptions concerning the use of their system, for example, an English-speaking user in United States. Rather, they must internationalize their software. As part of such internationalization, developers should concern themselves with properties of users of their systems such as language and location.
The world's software consumers are not fluent in a single language but rather are multilingual. Accordingly, software consumers can speak and interact in hundreds of different languages. Furthermore, individual users may be multilingual and feel more comfortable utilizing one language rather than another. Thus, software must be easily operable and functional in a myriad of disparate languages. One current software problem, produced at least by the use of multiple languages, concerns collation.
Collation generally concerns the comparison and ordering of data. In fact, collation is a fundamental aspect of computing. For example, users will likely need to locate strings, compare strings, and sort database records. The problem is that collation is not uniform. It varies by, among other things, language, culture, usage and customs. For example, in Swedish z<ö and in German ö>z. Handling of strings is further complicated by the fact that the same letter can be represented in different ways. For instance, the letter é can be represented either as a single character or as the combination of the underlying character “e” and the accent. Similarly, a single letter can be represented by different characters, for example the letter “β” might be written as “ss” in German. Improper handling of internationalized strings can lead, to among other things, subtle security bugs such as the infamous Turkish I problem, where the FILE:// prefix in a URL is trying to be located utilizing the test “if(url.ToUpper( ).Left(4)==“FILE”).” In this test, prior to comparing a string the string is converted to uppercase. However, converting “file” to uppercase in Turkish yields “FİLE” and hence the test fails unexpectedly.
A further matter of concern for internationalization of software includes time. When a program contains a date and time, one needs to know in which time zone such date should be interpreted. If a program indicates that a meeting has been set or a television show will start at 3 p.m., no one knows for sure what time 3 p.m. is without the specification of a time zone. As per the meeting request, some could interpret the time to be in the time zone in which they are located, while others could view the time as the time zone of the meeting requester. With respect to television, it would be confusing as to whether the time specified relates to the time zone of the viewer or Eastern Standard Time because that it the way shows are customarily listed. Moreover, writing and understanding time collation in software programs would be nearly impossible without specification of the time and respective time zone.
Conventional technologies have addressed collation in many different and problematic manners. For example, some database systems support collation per column. In other words, collation data could be attached to entries of a particular column. For instance, one could have a name collation in English and German. However, a single column could not contain both English and German stings. Thus, if a database user had customers from several countries they must put them in separate tables. Moreover, database languages are weakly typed languages, which are problematic for producing safe and reliable software. Another way conventional technologies provide collation is per thread. Here, collation information is specified at a global level. Hence, in order to interpret the comparison String1>String2 attention is paid to the global declaration. However, this system is not only weakly typed but it only allows use of a single language at a time. Yet another way collation is handled by conventional systems is via instance. In essence, each instance must carry around collation information. For example:                SqlString s1=new SqlString(“llegar”, Spanish);        SqlString s2=new SqlString(“lugar”, English);        Int r=s1.CompareTo(s2);Here, s1 is a Spanish string and s2 is an English string. This technique is disadvantageous at least because it is expensive to carry around additional information for each instance. Moreover, although this comparison would pass at compile time because the types are the same (namely a string), it would fail at runtime because a Spanish string cannot be compared to an English string. Thus, this methodology is also weakly typed and not suited for production of safe and reliable software.        
Accordingly, there is a need in the art for an efficient and strongly typed system and method of collation information specification and utilization.